Algorithmically Determining Store-and-Forward MTA Relays Using DomainKeys

Store-and-forward MTA relaying servers have frequently presented problems to various antispam techniques, such as IPbased reputation or email authentication. Algorithms that find email relaying servers can use knowledge about a domain’s outbound IP addresses combined with cryptographic domain authentication frameworks such as DomainKeys. This paper presents one such algorithm. 1.Why find relaying servers? In this paper, the term relaying will be used to describe the situation where messages intended for an email user are systematically and automatically delivered to a non-local address. Many industry terms are used for this action: forwarding, redirection, lifetime email addresses, etc. The feature is prevalent in university’s alumni email accounts and Internet access providers. Unmoderated mailing lists also have many of the characteristics of forwarding servers. In this paper, the term is specifically for MTA relays and not used to describe the use of a Forward button or Bounce/redirect option in a MUA. Email that has traversed a store-and-forward MTA relay is generally indistinguishable from a forgery to a receiving system. Without email authentication technology, the connecting IP address is the only data piece of an email that is not forgeable. In a relaying scenario, the IP address connecting to the final recipient’s mail server is not one associated with the message’s originator. Instead, the connecting IP address will be present in a Received header, perhaps several below the one describing the final network hop. Generally, this data about the originator is not trustable by the receiving system, as a spammer can pretend to forward an email by adding a faux Received header at the top of their transmission. However, if a receiver had a list of servers that it trusted to properly relay, rules could be developed to parse Received headers to find the originator and then apply IP-based reputation filters, or authenticate the email using path-based models such as SPF or Sender ID that are ineffective in relaying situations. Relay servers are also likely false positive candidates for sender reputation. With spam email between 65-85% of normal traffic, relaying servers will likely redirect similar percentages of spam. This rate of spam would mark the relaying server’s reputation as negative, because the spam rate would be orders of magnitude worse than a best practices sender’s spam complaint rate per message. As a result, relays are more likely to be treated as second class (or worse) mail, experiencing deliverability problems such as tagged false positives and degraded performance from greylisting [4] and teergrubing [5], or even message rejection. If a receiver can algorithmically determine a forwarding server, different rules could be applied to avoid this treatment. This need to reliably determine relay servers creates a transient trust dilemma for the receiving system. If the receiving system blindly trusts Received headers to determine relays, it may enable the spammer to forge email and slip by filters, an unacceptable risk. If it could algorithmically determine the auto-forwarding servers, these risks would be significantly mitigated.